Nessuno schema come questo impedisce ad un determinato attaccante di attivare la "funzione di debug", con il semplice espediente del reverse engineering del codice per individuare la parte che, nel codice del software, assomiglierà a:
if (is_good_password(password)) {
activate_debug();
}
e trasformalo in:
if (true) {
activate_debug();
}
che di solito è solo una questione di trasformare un salto condizionato in un salto incondizionato, o un non salto incondizionato (cioè un nop opcode). Non è nemmeno difficile da fare, anche in grandi software (ad es. L'ho fatto una volta per Windows 2000, per consentire di testare un personalizzato CSP - CSP deve essere firmato, e la soluzione fornita da Microsoft per disattivare la verifica della firma sulle piattaforme di sviluppo era valida solo fino a Win2k SP2, o WinXP, mentre avevo un Win2k SP4, quindi dovevo hackerare il advapi32.dll , che mi ha richiesto 3 ore).
Detto questo, se vuoi solo verificare una password, il modo più semplice è di memorizzare nel tuo software un token di verifica della password, cioè un valore hash calcolato sulla password. Non c'è bisogno di portare tutto l'armamentario delle firme digitali! Solo un semplice hash, e questo può ospitare password di qualsiasi lunghezza. Il software incorpora il valore hash; quando viene inserito l'URL "debug", blocca la parte dopo " debug/ " e vede se corrisponde al valore hash registrato. Pertanto, la password non appare nel codice software stesso (né in testo chiaro, o semplicemente "codificato"), e puoi usare una "password" abbastanza breve da essere digitata.
Le firme digitali vanno bene solo se hai un numero illimitato di "Debbies", e vuoi essere in grado di dare una "password di debug" a ogni Debbie, in modo che ogni Debbie abbia la sua password distinta dalle password date agli altri Debbies, e volete rendere impossibile una Debbie malvagia, indipendentemente da quanto ingegneria inversa, per ricalcolare le altre password da quella che lei ha già (se hai solo, diciamo, 20 Debbies, puoi includere solo 20 valori hash nel tuo codice; per "illimitato" intendo "potenzialmente milioni"). Questo è uno scenario piuttosto specifico. Un esempio sono le "chiavi del prodotto": le firme digitali potrebbero teoricamente vanificare i generatori di chiavi del prodotto. Tuttavia, la firma digitale più potente non farà meglio di un hash della password contro un utente malintenzionato che esegue alcune ore di reverse engineering sul codice per individuare l'opcode di salto condizionale corretto. La firma non protegge contro l'accesso illecito al codice di debug; protegge solo contro estendendo un accesso illecito a una scala industriale, assegnandolo a molti altri clienti senza richiedere una modifica locale del codice - un cosiddetto "hack" .
Per la funzione di hash, in caso di dubbio, usa SHA-256 - se (e solo se) la "password" è lunga e abbastanza casuale (ad esempio 128 bit casuali). Se alla Debbie è permesso scegliere una password "significativa" (una che un essere umano sarà in grado di ricordare, invece di averla scritta su un pezzo di carta), allora dovresti usare una funzione di hash che resiste agli attacchi del dizionario, per esempio PBKDF2 o bcrypt .
Non utilizzare la modalità "criptare con la chiave privata" per descrivere una firma; è una spiegazione terribile, che non funziona per tutti gli algoritmi di firma. È solo un modo storico con cui RSA è stato presentato per la prima volta, ma anche per RSA è sbagliato: non ci vuole padding in considerazione e il padding è essenziale per la sicurezza (vedi PKCS # 1 ). Lascia perdere. Non c'è niente di sbagliato in "usare la chiave privata per firmare alcuni dati" e "usare la chiave pubblica per verificare alcuni dati".